메시지 큐 도입 위치 결정 — 트레이드오프
NOTE
디바이스(현장 장비) → 중계 서버 → 관리 서버로 이어지는 파이프라인에서, 메시지 큐를 어느 구간에 넣을지 결정하는 트레이드오프 정리. 실무(충전기 EV 서버)에서 일반화.
문제 상황
디바이스에서 발생한 이벤트가 여러 홉(hop)을 거쳐 최종 관리 시스템까지 전달되는 구조에서, 두 구간 중 어디에 메시지 큐를 넣을지 고민이 생긴다.
[디바이스] ──프로토콜A──▶ [중계 서버] ──HTTP──▶ [관리 서버]
① ②- ① 디바이스 ↔ 중계 서버 구간
- ② 중계 서버 ↔ 관리 서버 구간
판단 기준
1. 프로토콜 제약이 우선한다
메시지 큐(예: MQTT 브로커)를 넣으려면 그 구간의 통신 프로토콜이 큐가 요구하는 프로토콜과 호환돼야 한다. 디바이스가 이미 정해진 표준 프로토콜(예: OCPP)로만 통신하도록 고정되어 있다면, 그 구간에 MQTT 큐를 끼워 넣는 것 자체가 애초에 성립하지 않는다.
디바이스 쪽 프로토콜이 큐와 호환되지 않으면, 그 구간은 큐 도입 후보에서 자동으로 제외된다.
2. 남은 구간에서 비용 대 효과를 따진다
프로토콜 제약이 없는 구간(위 예시에서는 ②)이 메시지 큐 후보가 된다.
| 항목 | 큐 도입 시 장점 | 큐 도입 시 단점 |
|---|---|---|
| 안전성 | 수신측(관리 서버) 장애 시에도 메시지가 유실되지 않고 큐에 쌓임 | — |
| 확장성 | 프로듀서/컨슈머를 독립적으로 스케일 가능, 비동기 처리로 결합도 감소 | — |
| 지연(latency) | — | 큐를 거치는 만큼 필터링·라우팅 단계가 늘어나 약간의 지연(delay) 발생 여지 |
| 운영 비용 | — | 브로커 자체의 인프라 구축·운영 비용 추가 |
3. 결론 도출 방식
“안전성·확장성이 지연·운영비용보다 중요한 구간인가”를 구간별로 따져서 결정한다. 실시간성이 중요한 최전단(디바이스↔중계) 구간보다, 후단(중계↔관리 서버, 배치·집계·알림성 처리가 섞이는 구간)이 보통 메시지 큐 도입의 이득이 더 크다 — 후단은 이미 한 번 정규화된 데이터를 다루므로 약간의 지연을 감수할 여유가 있고, 관리 서버 쪽 부하 스파이크를 큐가 흡수해줄 수 있기 때문이다.
일반화 — 이 판단을 다른 구간에도 적용하려면
- 프로토콜 호환 여부를 먼저 확인한다 — 안 맞으면 그 구간은 큐 후보에서 제외.
- 남은 구간에서 장애 격리(수신측 다운 시에도 유실 없음) 와 비동기 확장성이 필요한지 판단한다.
- 그 이득이 추가되는 지연과 운영 비용을 상회하는지 최종 확인한다.
메시지 큐는 “무조건 넣으면 좋은 것”이 아니라, 구간별 제약(프로토콜)과 트레이드오프(안전성/확장성 vs 지연/비용)를 함께 따져야 하는 아키텍처 결정이다.